Transmitting messages over a network

ABSTRACT

A method of transmitting a message over a network from a sender to a receiver, comprises the steps of: taking a message (Coin) to be signed by the sender; signing the message into a digital signature (e, y) of the sender (steps  56,58 ), the digital signature being generated as a function of that message using public and secret signature generators (x, r) of the sender, a private key (s) of the sender, and other publicly known values (a, p, q); and transmitting the signed message over the network to the receiver (step  60 ); characterised in that: the message to be signed by the sender incorporates a first value (f(x)) which is a first predetermined function (such as a secure one-way hash function) of the sender&#39;s public signature generator (x) (step  48 ). It is thus possible that the incorporation of a proper first value can be verified by a receiver of the message who requires the sender to sign the message using a public signature generator, and furthermore that if a sender signs and transmits the same message more than once, the private key of the sender can be derived from the plurality of signed messages and a relationship between the public and private signature generators.

TECHNICAL FIELD

This invention relates to a method of and apparatus for transmittingmessages over a network, and in particular, but not exclusively, isconcerned with “cash purchases” over a network such as the Internet.

BACKGROUND ART

Today, the business potential of the Internet, especially, of theworld-wide-web applications, forms a new dimension in electroniccommerce. It is believed that information purchases will form a very bigpart of the activities in the Internet electronic commerce. A typicalnature of this form of commerce is to deal with a large volume oflow-value payment transactions. The usual price for a few informationpages can be as low as several cents. Various techniques proposed formacro payments are not suitable to be used here as transaction fees maywell exceed the value of payments. Furthermore, these techniques do notpreserve a proper purchaser's anonymity which can be an essentiallyimportant feature in information purchases. On the other hand, the vastdiversity of the Internet information services (e.g. web-based services)means that the subscription-based services may not be very attractive toa large number of one-off viewers. It is thus reasonable to considerfacilitating information purchases over the Internet with a cash-likepayment instrument.

Chaum, U.S. Pat. No. 4,759,063, discloses a blind signature techniquefor cash-based electronic commerce. The subject of electronic cash hasthereafter been widely studied and many techniques proposed to tacklevarious unsolved problems. Actual systems have also been implemented fortrial use. However, when considering information purchases over theInternet, these previous techniques have various limitations.

Firstly, an evident limitation in various previous off-line digital cashtechniques is the high system complexity. In some of these techniques, acoin will have too big a data size to be economically used (containing alarge number challenge terms for detection of cheating); some alsorequire using complex challenge-response interactions between the payerand payee for each coin spent (a non-cash feature); others criticallyrely on using tamper-resistant devices (expensive smartcards with abuilt-in observer to monitor transactions). Systems relying onsmartcards also have a limitation in quick deployment over the Internetas most home/office computers today are not readily equipped with asmartcard reader. In some of the smartcard cash techniques, the built-inobserver works itself without co-working with the cardholder's privatekey. Such techniques are potentially dangerous as compromising onesmartcard devastates the whole system. Further, considering afundamental principle of cryptography that a re-usable key with alimited length must have a limited lifetime, then systems using asystem-wide observer also pertain to a high running cost due to the needof changing the observer in the system-wide devices from time to time.

Secondly, schemes using on-line banks, though they can prevent doublespending (each coin is checked against replay during the time ofpayment) rather than merely detect it afterwards (yet still with a goodanonymity service) are obviously not suitable for micro-payments. Here,the problem is not only in terms of economy, but also systemperformance. Banks are far too few compared with the vast number ofsmall cash transactions; by processing on-line requests for suchtransactions, they are doomed to becoming serious system bottlenecks.

The present invention is concerned with enabling one or more of theseproblems to be solved, and it will be shown that an example of theinvention can solve most, if not all, of these problems.

DISCLOSURE OF INVENTION

In accordance with a first aspect of the present invention, there isprovided a method of transmitting a message over a network from a senderto a receiver, comprising the steps of: taking a message (Coin) to besigned by the sender; signing the message into a digital signature (e,y) of the sender, the digital signature being generated as a function ofthat message using public and secret signature generators (x, r) of thesender, a private key (s) of the sender, and other publicly know values(a, p, q); and transmitting the signed message over the network to thereceiver; the message to be signed by the sender incorporating a firstvalue (f(x)) which is a first predetermined function (such as a secureone-way hash function) of the sender's public signature generator (x)into the message to be signed by the sender.

It is thus possible that the incorporation of a proper first value canbe verified by a receiver of the message who requires the sender to signthe message using a public signature generator, and furthermore that ifa sender signs and transmits the same message more than once, theprivate key of the sender can be derived from the plurality of signedmessages and a relationship between the public and private signaturegenerators.

The signature preferably includes a second value (e) which is a secondpredetermined function (h( )) (such as a secure one-way hash function)dependent on the first value (f(x)).

The signature preferably includes a third value (y) which is a thirdpredetermined function of the secret signature generator (r), the secondvalue (e), the private key (s) of the sender, and at least one (q) ofthe publicly known values.

The message to be signed by the sender preferably incorporates a fourthvalue (g(v)) which is a fourth predetermined function (g( )) (such as asecure one-way hash function) of a public key (v) of the sender.

This latter feature may be provided independently of the first aspect ofthe invention. Therefore, in accordance with a second aspect of thepresent invention, there is provided a method of transmitting a messageover a network from a sender to a receiver, comprising the steps of:taking a message (Coin) to be signed by the sender; signing the messageinto a digital signature (e, y) of the sender, the digital signaturebeing generated as a function of that message using public and secretsignature generators (x, r) of the sender, public or private keys (v, s)of the sender, and other publicly known values (a, p, q); andtransmitting the signed message over the network to the receiver; themessage to be signed by the sender incorporating a fourth value (g(v))which is a fourth predetermined function (g( )) (such as a secureone-way hash function of the public key (v) of the sender into themessage to be signed by the sender.

In accordance with a third aspect of the present invention, there isprovided a method of verifying a signed message received over a network,the signed message purporting to have been transmitted in accordancewith the method of the first aspect of the invention, comprising thesteps of: calculating an apparent public signature generator (z) of thesender using the signed message, a public key (v) of the sender andother publicly known values (a, p); calculating a fifth value (f(z))which is the first predetermined function (f( )) of the apparent publicsignature generator (z); and comparing the fifth value (f(z)) with thefirst value (f(x)) incorporated in the received signed message.

In the case where a second value as defined above is expected in thereceived signed message, preferably the verifying method includes thefurther steps of: calculating a sixth value (e) which is the secondpredetermined function (h( )) of the fifth value; and comparing thesixth value (e) with the second value (e) included in the receivedsignature.

In the case where a fourth value as defined above is expected in thereceived signed message, preferably the verifying method includes thefurther steps of: calculating a seventh value (g(v)) which is the fourthpredetermined function (g( )) of a public key (v) of the sender receivedover the network; and comparing the seventh value (g(v)) with the fourthvalue (g(v)) incorporated in the signed message.

This latter feature can be provided independently of the third aspect ofthe invention. Therefore, in accordance with a fourth aspect of thepresent invention, there is provided a method of verifying the publickey of the sender of a signed message received over a network, thesigned message purporting to have been transmitted in accordance with amethod according to the second aspect of the invention, comprising thesteps of: calculating a seventh value (g((v)) which is the fourthpredetermined function (g( )) of the public key (v) of the senderreceived over the network; and comparing the seventh value (g(v)) withthe fourth value g(v) incorporated in the signed message.

The invention also encompasses apparatus which is adapted to perform anyof the methods described above.

DESCRIPTION OF DRAWINGS

A specific embodiment and examples of the invention will now bedescribed, by way of example, with reference to the accompanyingdrawings, in which:

FIG. 1 is a schematic diagram of a sender's computer showing thesetting-up of various parameters, common to the prior art and apreferred embodiment of the invention;

FIG. 2 is a schematic diagram of a sender's computer showing steps takenin the prior art to send a message;

FIG. 3 is a schematic diagram of a receiver's computer showing stepstaken in the prior art to verify a received message;

FIG. 4 is a schematic diagram of a Bank's computer showing steps takenin the preferred embodiment of the invention to supply a Coin;

FIG. 5 is a schematic diagram of a sender's computer showing steps takenin the preferred embodiment of the invention to pay the Coin to areceiver; and

FIG. 6 is a schematic diagram of a receiver's computer showing stepstaken in the preferred embodiment of the invention to verify a receivedCoin.

BEST MODE OF CARRYING OUT THE INVENTION, & INDUSTRIAL APPLICABILITY

In an example of the invention described below, an off-line micro-cashtechnique is set out which is suitable for purchasing information (andother) services over the Internet. A number of cash features will besupplied. These include: purchaser's anonymity, identifying a doublespender with strong proof, using no on-line banks for payment, beingindependent of tamper-resistant devices, and providing a coinsub-divisible to arbitrary denominations (an important feature suitablefor a single page information purchase). The main goal is to supplythese services at a very low cost affordable by the system in accordancewith the typically low values of per-payment transactions. This goal isachieved by the system simplicity in terms of small data size forrepresenting coins (a payment of an arbitrary amount can be sent in lessthan one kilobyte), and in terms of no need of interactivecommunications between purchaser and merchant (a payment can be made ina single email).

Taking a pragmatic approach to spender's anonymity, the anonymityservice in the example of the invention is based on a trust thatpublic-key certification authorities (CA's) do not collude with systemsuppliers (banks). Such a collusion will give a bank a cheap way to linkeach coin with its spender. Collusion between a bank and merchants canalso defeat the anonymity service. However, it will be seen that, unlessthe collusion is on a large scale and therefore very costly for a bank,it will have a very limited extent of damage to the spender's anonymity.Nevertheless, such a pragmatic, low-cost anonymity service isappropriate to the system. From the system suppliers' point of view,low-cost is essential considering the low values of typicaltransactions. Even from the consumers' point of view, it is believedthat this weak sense of anonymity will be acceptable by many users asthey will regard the convenience of securely sending money over theInternet to outweigh the extremely small probability of collusionsbetween a bank and a CA, or between a bank and a vast number ofmerchants. People's attitude toward sending money over the Internet isexpected to change. For instance, sending a few cents or a couple ofdollars over the Internet will no longer be considered as “dangerous” assending one's credit-card number (even encrypted).

Similar to all other off-line cash techniques, a double spender will beidentified after a double spending has occurred. However, a uniquefeature in the after-the-fact identification is that the identificationis in terms of discovering the double spender's private key by the bank.Such a result of identification is effective in the following scenario.The bank can simply show the double spender's private key to theappropriate public-key certification authority; the associatedpublic-key certificate can then be revoked instantly andunconditionally. Thus, no matter how small an amount of money (even asingle penny or cent) is double spent, there are no possibly expensivelegal requirements for the bank to process regarding the revocation ofthe certificate in question. This identification method is thereforeparticularly suitable for micro-payment transactions. The method alsostrongly deters double spending: a new certificate for a new pair ofpublic/private keys for an identified double spender can be madesufficiently expensive that the price far outweighs the benefit ofdouble spending low-value coins.

The identification technique to be described uses a variation ofSchnorr's signature scheme. Given a data in a certain format, exactlyonly one signature can be made on the data. Making more than onesignature on the same data will lead to disclosure of the private keythat is used for generating the signatures and for proving the identityof the signer.

Firstly, a description will be given of the scheme disclosed by Schnorrin U.S. Pat. No. 4,995,082, with reference to FIGS. 1 to 3. As apublic-key crypto-algorithm, Schnorr's signature scheme has a pair ofpublic/private keys. In Schnorr's scheme, users in the whole system canshare some public values as part of their public keys. First, choose twoprimes, p and q. Here, p is a large prime (e.g. p>2⁵¹²) such that thediscrete logarithm problem in Z_(p)* is intractable; q is also a largeprime (e.g. q>2₁₄₀) and q| (p−1). Then, choose a number αεZ_(p)* withorder q (q is the smallest prime number satisfying α^(q)=1 (mod p); suchan α can be computed as the (p−1)qth power of a primitive element moduloq). It will be assumed that all parties in the system share thesenumbers.

To generate a particular public-key/private-key key pair, a prospectivepurchaser, herein called “Alice”, chooses a random number less than q instep 12. This is her private key, s. Then, in step 14 calculate:

v=a ^(−s)(mod p)  (1)

where v is Alice's public key.

Schnorr's signature scheme uses a secure one-way hash function. Let h( )denote a secure one-way hash function. It should be computationallyinfeasible to find two input values x≠x′ such that h(x)=h(x′); also withrespect to the input, the output from h( ) behaves like an oracle, inthat one cannot generate an expected output value by algorithmicallymanipulating the input values.

To make a signature on message m, Alice picks a random number r, lessthan q (step 16), and does the following computations:

Step 18 x=(a ^(r) mod p)  (2)

Step 22 e=h(m, x)  (3)

Step 24 y=((r+se)mod q).  (4)

The signature on the message m is the pair e, y. We will call the othertwo numbers, r and x, “secret signature generators” and “publicsignature generators”, (or SSG, PSG), respectively. In step 26, Alicesends the signature to a merchant, herein called “Bob.” Bob verifies thesignature by computing:

Step 34 z=(a ^(y) v ^(e) mod p)  (5)

and checking if

Step 36 e=h(m, z).

If the equation holds, in step 38 he accepts the signature as valid.

Schnorr's signature scheme gets its security from the difficulty ofcalculating discrete logarithms. The difficulty means that the privatekey s cannot be easily derived from the public key v even with theirrelationship shown in Equation (1). Similarly, the secret signaturegenerator (SSG) r cannot be easily derived from the non-secret number zfrom their relationship in Equation (2) (z is equal to the publicsignature generator (PSG) x).

Besides relying on the difficulty in computing discrete logarithms, thesecurity of the one-way hash function h( ) also plays an important rolein Schnorr's scheme. This security derives from the difficulty inpreparing input data that maps to a given output value, or to find twoinput data that collide to the same output value. When Bob verifies thesignature, he knows from the property of the hash function that, withoutknowing Alice's private key, it is computationally infeasible to createthe consistency among the numbers e, y, z and m which are related underthe hash function used. The hash function h( ) is essentially an oracle;it is difficult to prepare input data that map to a given output value.

Note that the SSG r must be treated as one-time material. It must not beused more than once to generate different signatures. Assume otherwise,an SSG r has been used before by Alice in a signature on some message mand now Alice re-uses it to generate a new signature on a differentmessage m′. Let e and y be the numbers used by Bob during theverification of the signature on m, and e′, y′ be those that correspondto the new message m′. Now that m′≠m, from Equation (3) and the propertyof the hash function we know almost for sure (with an overwhelmingprobability) that e′≢e (mod q). If these non-secret numbers (e, y) and(e′, y′) are acquired by Bob, he can compute Alice's private key s bysubtracting two instances of Equation (4) and obtain:

s=((y−y′)/(e−e′)mod q)  (6)

On the other hand, as long as Alice does not repeat using any old SSGwhen creating a new signature, then subtraction of Equation (4) willonly result in y−y′≡r−r′+s(e−e′) (mod q). Here the value r−r′≢0 (mod q)remains to be a secret that protects the private key s just in the sameway as in Schnorr's scheme. More precisely, Alice should not use an SSGwhich is related to an old SSG in any known algorithmic way. As long asthis precautionary measure is taken, no arithmetic calculation is knownso far that allows one to derive the signer's private key from differentinstances of signature values. In fact, the digital signature standard(DSS) proposed by NIST uses essentially the same principle to protectthe signer's private key.

The example of the invention employs the property illustrated inEquation (6) to identify a user who has used certain data more thanonce, and the identification can be supported with a strong proof. Theidea is to create a consistent relationship between a piece of data tobe signed (a condition for using the data) and a PSG (x or z inSchnorr's scheme) used for making the signature. In other words, letAlice (signer) sign a piece of data, and let Bob (signature verifier) beprovided with a method to know that, for the data in question, Alice hasused a required PSG (and hence its correspondent SSG, see below). If awrong PSG has been used, then Bob will not accept the signature even ifit is valid under the usual usage of Schnorr's scheme.

Note that it is impossible for Alice to find two SSG's r≢r′ (mod q) thatmap to PSG's satisfying x≡x′ (mod p). Being able to do so would allowAlice to sign the same data twice without disclosing her private key.This is because from x≡x′ (mod p), i.e. a^(r)≡a^(r)′ (mod p), we havea^(r−r)≡1 (mod p); but a has order q which means q is the smallestnon-zero number satisfying a^(q)≡1 (mod p), so it has to be the casethat r≡r′ (mod q).

This idea finds a good application in designing an electronic cashtechnique in accordance with the invention. A double spender of a coinwill be identified with a strong proof whereas honest users enjoy theiranonymity. Below there follows a description with reference to FIGS. 1and 4 to 6 of an example of simple cash coin in accordance with theinvention which has this property obtained from using a variation ofSchnorr's scheme.

Let Alice have a coin constructed as a result of her cash withdrawalfrom a bank (not necessarily from her own bank). The coin has beendigitally signed by the bank to be worth a certain amount of value, andthis can be validated by any receiver of the coin (with the use of apublic-key certificate authority, CA). The bank's signature on the coinfollows Chaum's blind signature technique. The coin is blinded in that,once Alice has completed the withdrawal, the bank then loses any linkbetween the coin, and the withdrawer, Alice. For conciseness, in thisspecification, a description of the known anonymous cash withdrawalprocedure based on using the blind signature technique has not beenincluded, but reference is directed to patent document

During the withdrawal time, the coin is constructed such that itintegrates a pair of one-way hashed values, f(x), g(v). The first valueis mapped from a PSG x chosen by Alice, and the second from the Alice'spublic key v. Note that the whole withdrawal process need not useAlice's public key v at all. This is because the bank need not check thecorrectness of these two hashed values. Later it will be seen that Alicewill be wasting her money if she integrates incorrect values into acoin.

Let Sig_(B) be the bank's blind signature. We can denote a coin asfollows:

Step 48 Coin=Sig_(B)(C, f(x), g(v)).

Here C is called a “coin pseudonym”, which is recognisable as a bankcoin by any receiver who can verify the bank's blind signature. InSchnorr's scheme, a pair of SSG, PSG can be pre-computed. So there willbe no problem for Alice to prepare PSG x (and the respective SSG r)during the withdrawal time.

When Alice pays Coin to a merchant, she is required to sign thepseudonym C using the PSG x integrated in Coin. Herein this signature iscalled a “spending signature”. The spending signature on C shouldinclude the merchant's identity and a timestamp stating the spendingtime. Namely, the message to be signed (m in Equation (3)) becomes:

C, merchant_id, timestamp.

The spending signature uses a variation of Schnorr's original scheme:the value e will be computed by the following equation different fromthe original form in Equation (3), namely:

Step 56 e=h(C, merchant_id, timestamp, f(x))  (7)

In this variation, a hashed valuef(x) is used, rather than directlyusing x as in the case of the original Schnorr's scheme (cf Equation(3)). It will be shown below that this variation will prevent the bankfrom discovering Alice's public key (when Alice does not double spend).In order to let the merchant verify the spending signature, Alice shouldalso send her public key v together with a valid key certificate to themerchant. Let Cert(X, K) be a public-key certificate issued by awell-known CA certifying the public key K to the principal X, and let “XY: message” denote that the principal X sends the message to theprincipal Y. The payment message will be seen as follows:

Payment: Alice Merchant: Coin, merchant_id, timestamp, e, y,Cert(Alice_id, v)

Here, the value y is computed by Alice as in Equation (4), see step 58.The merchant will verify the spending signature using Alice's public keyv. He first uses the values e, y, a, v to compute z as in Equation (5),see step 62. Then, he verifies if Equation (7) holds by using f(z) inplace of f(x), see step 64. He also checks the correct use of the PSG xand the public key v. The two correct uses mean that z and v can behashed using f( ) and g( ) to the respective two hashed values in Coin,as shown in steps 66, 68. The payment will not be accepted if anincorrect PSG or public key is used, because the merchant will havetrouble in redeeming an incorrectly signed coin.

Later, the merchant will redeem the coin by depositing the following“coin deposit” data to the bank:

Deposit: merchant Bank: Coin, merchant_id, timestamp, E(z), e, y  (8)

Here, E(z) denotes that the merchant encrypts the value z with thepublic key of CA. Note that using a CA's public key for encryption seemsto add a new role for CA's. However, it will be seen later that this isa measure to detect a rare case of double spending (rare because it isthat the double spender colludes with a merchant). Note that when adouble spending occurs, a CA will be approached anyway in order torevoke the key certificates of those responsible. From this point ofview, no essentially new role will be added to CA's.

The merchant must digitally sign the coin deposit. The signature notonly means that the merchant has properly dealt with the payment, butalso serves to prevent the bank from altering the data.

There now follows an analysis of the operation of the scheme describedabove. First, assume that Alice does not double spend her coins. Thenher anonymity of spending the coins will be protected. This is becausethe coin-deposit in Equation (8) does not contain any information aboutspender's identity. Note that the anonymity here is in a sense that themerchant does not collude with the bank. It suffices for the merchant tobe non-collusive if he just throws away the values v and z after thecoin has been validated and accepted. v would directly identify Alicesince it is her public key and its connection with her can be found froma suitable CA. More obscurely, the value z, if acquired by the bank, canalso be used to derive v. This is because of the following congruence:

v ^(e) ≡z/a ^(y) (mod p)  (9)

Once v^(e) is known, it is easy to reveal v as:

v=(v ^(ed) mod p) where ed≡1 (mod p−1)  (10)

The bank has e to compute d above. This is analogous to a broken RSAalgorithm where the factors of the modulus are known. Without givingthese values to the bank, it is infeasible for the bank to find who hasspent the coin. Brute-force searching through the public-key space formatching values g(v) or f(x) (here, using f(x) is to check if acandidate result of Equation (5) can be hashed to f(x) in Coin) iscomputationally infeasible (the public-key space is vast) unless thebank can acquire a sufficiently large number of public keys of the usersin the system (which should form a trivially small subset of the wholepublic-key space). This can be prevented by implementing thecertification authorities that do not permit downloading public keys orcertificates. Normal CA's should disallow such an abuse.

Now assume that the bank sees duplicated copies of the coin pseudonym C.This may be as a result of either (i) Alice's double spending, or (ii)the merchant's replay, or (iii) a collusion between Alice and themerchant.

In the first case (i), Alice double spends. It has been analysed thatthe differences in either merchant_id or timestamp will result in twopairs of (e, y) and (e′, y′) where e ≢e′(mod q), and hence y≠y′, with anoverwhelming probability. These two pairs will be sufficient for thebank to discover Alice's private key s using Equation (6), and furtherobtain her public key v from Equation (1). The bank can verify thecorrectness of the revealed public key by checking if it can be hashedto g(v) in Coin. (An incorrectness indicates a collusion between Aliceand the merchant and this will be dealt with in Case (iii).) Such anidentification is effective in the following scenario. The bank cansimply show the double spender's private key to the appropriatepublic-key certificate authority; the associated public-key certificatewill be revoked instantly and unconditionally. Thus, no matter how smallamount of money (even a single penny) is double spent, there are nopossibly expensive legal requirements for the bank to comply regardingthe revocation of the certificate in question. This identificationmethod is therefore particularly suitable for micro-paymenttransactions. The method also strongly deters double spending: a newcertificate for a new pair of public/private keys for an identifieddouble spender can be made sufficiently expensive so that the price faroutweighs the benefit of double spending the low-value coins.

Note that Alice cannot use different key pairs (certified or not) tosign different spending signatures on the same coin pseudonym (try todouble spend without disclosing her identity). This is because themerchant will only accept a signature that can be verified using thepublic key that can be hashed to the value g(v) in Coin. Similarly,Alice cannot use a wrong PSG to create a spending signature because themerchant will only accept one that can be hashed to the value f(x) inCoin. Permitting a spender to use incorrect public keys or incorrectPSG's will lead to identifying the merchant as colluding with the doublespender. Various cases of such collusion will be discussed in Case(iii).

In the second case (ii), the merchant double deposits. If Alice does notdouble spend, then the merchant cannot double deposit a coin receivedfrom Alice where the different copies of coin-deposit in data set (8)have different yet valid spending signatures of Alice. Clearly, this isdue to the inability to forge Alice's spending signature. Thus, thepossibility for the merchant to double deposit a coin is confined to thefollowing way: he simply replays the coin-deposit in data set (8) withidentical data. It is easy for the bank to discover the replay andthereby only one instance of deposit will be redeemed.

Note that the merchant is required to sign the coin-deposit digitally inthe data set (8). Therefore, depositing incorrect or gibberish data asspending signatures in order to achieve double deposit will lead toidentifying the merchant as malicious. In Case (iii), cases will be seenof identifying malicious merchants.

In the third case (iii), Alice and the merchant collude. A collusionwill make sense only if it does not lead to identifying Alice and at thesame time it lets the merchant deposit coins with consistent andnon-identical spending signatures.

It seems that in order to achieve the above, the merchant has to permitAlice to use incorrect keys (uncertified or not matching g(v) in Coin),or incorrect PSG's, to sign the spending signatures. For instance, inthe case of permitting using incorrect keys, a coin can be double spentby a person who has different (certified or not) key pairs, or bydifferent people (e.g. members in the same family).

In these circumstances, upon seeing the duplicated coin pseudonym C, thebank's computation using Equation (6) will not correctly reveal Alice'sprivate key. In an overwhelming probability, the revealed key will notbelong to anybody (probability see below). For instance, let twospending signatures (e, y) and (e′, y′) have been created with the useof two different private keys S₁ and S₂, respectively. Then, usingEquation (6) will result in the following value:

s′=((s ₁ e−s ₂ e′)/(e−e′)) (mod q)

Similarly, if the merchant permits Alice to use incorrect PSG's whichare mapped from two different SSG's r₁ and r₂, then Equation (6) willnot disclose Alice's true private key either, but

s′=(((r ₁ −r ₂ +s(e−e′))/(e−e)) (mod q)

Other wrong forms of “private keys” can also be expected from mixed usesof wrong keys and wrong PSG's. Let v′ be the matching “public key”computed from Equation (1) using s′. Then, in an overwhelmingprobability, v′ will be found to have not been certified to anyone. Theprobability that v′ happens to be someone's public key is equal to thatof having correctly guessed someone's private key.

If duplicated coin-deposits with different spending signatures have beendeposited from the same merchant, then he is certainly malicious becauseeither he has used incorrect public keys (cannot be hashed to g(v) oruncertified), or has permitted the use of incorrect PSG's during thetime of verifying the spending signatures.

If duplicated coin-deposits with different spending signatures have beendeposited from different merchants, then, at least one of the merchantsis malicious and needs to be identified (e.g. Alice properly spends acoin with an honest merchant and then double spends the same coin withcollusive one). In such a situation, the CA has to be approached fordecrypting the values E(z) that have been deposited from the respectivemerchants. With the decrypted data, the bank has sufficient data todifferentiate an honest merchant from malicious ones. An honest merchantis related to a quantity z which can be hashed to f(x), and can be usedto compute a correctly certified public key v (using Congruence (9) andEquation (10)) that can be hashed to g(v). Any quantity z not satisfyingeither of these two tests identifies a malicious merchant. The merchantcannot be framed because he has digitally signed the coin-deposit.

Note that when the CA is used, the identity of the spender becomes knownto the bank. However, the bank cannot abuse this method with a trueintention to identify a non-double-spender (e.g. to claim falsely adouble spending) because the CA will demand the bank demonstrate amerchant to be malicious whenever the CA is approached to decrypt E(z).The bank itself will be considered as malicious if at the end it cannotprove a merchant to be malicious.

It is interesting to point out that, as long as a coin is not doublespent or double deposited, the use of incorrect public keys or PSG's orhanding in gibberish spending signatures will not be discovered. Indeed,here, the bank need not be concerned of anything other than doublespending.

To this end, we see that the merchant is unable to help Alice to doublespend.

Note that in the rare case of double spending achieved by a collusionbetween Alice and the merchant, the use of CA for decrypting the messageE(z) seems to add a new role (or new burden) to CA. Nevertheless, thisseemingly new role is in fact covered by the current services of CA's.This is because, when a collusion occurs, the key certificates of theresponsible must be revoked anyway and the revocation is clearly part ofthe services of the CA's under the existing definition. A CA will neverbe approached if it is not requested to revoke a certificate.

As in Schnorr's scheme, the security relies on the difficulty ofsearching for collisions in hash functions. If Alice can preparecollisions between different PSG's such that f(x)=f(x′), then she candouble spend a coin using these two PSG's without being identified. Notethat searching for collisions for different PSG's should start fromsearching for different SSG's (i.e., Alice must know different r≢r′ thatsatisfy f(a^(r′)mod p)=f(a^(r) mod p); the exponentiation makes thesearch much harder than is usual for preparing hash-function collisions.

There now follows a description of specific example protocols for Aliceto pay cash coins in arbitrary denominations to various merchants, andfor merchants to deposit coins to the bank.

Each of the principals, Alice A, various merchants M₁, M₂, . . . and thebank B is equipped with public/private key pairs and each of the publickeys are properly certified to their owners by a well-known CA. So, eachprincipal can recognise the public key of another principal. Inparticular, Alice's key pair is in the form of Schnorr's signaturescheme described above.

During a withdrawal time Alice constructs a chain of coins C₁, C₂. . .C_(n) from the bank B by running an anonymous cash withdrawal protocol.These coins are constructed such that once they are in the hands ofAlice, the bank no longer has any link between Alice and them. Such ananonymous cash withdrawal can be achieved by using Chaum's blindsignature technique mentioned above.

The structure of these coins follows that of the “Payword” techniqueexpounded by Rivest and Shamir, or alternatively attributes to Lamport'soriginal password identification technique (also known as the “S/Key”technique). A secure one-way hash function, h( ), is used to hash asecret number repeatedly for n times. Let C_(n) be a secret numberchosen by Alice. The chain of coins is constructed as follows:

C _(i) =h(C_(i+1)) for i=0, 1,2,. . . ,n−1  (11)

She also chooses the first SSG r₁ and computes the respective PSG x₁,and lets B sign the pseudonym C₀:

Sig_(B)(C ₀ , g(v),f(x ₁), n)  (12)

Here, C₀ is called a “pseudonym-top”; it is not a coin. On the otherhand, C_(i) (1≦i≦n) are n coins. The signature (12) shows that bysigning the pseudonym-top C₀, the bank has essentially signed all of then coins. These coins are said to be under the pseudonym-top C₀. Thehashed values g(v) and f(x₁) have also been signed by the bank. So, thecorrect use of these coins can be verified later by a merchant using thepublic key v and the first PSG x₁. Note that, the blinded withdrawalprocedure need not be based on using the public key v.

Now Alice can start to spend coins. Starting with an initial payment ofi coins to (1≦i≦n) a first merchant M_(k) the idea is to disclose thecoin C_(i) to M₁. The coin C_(i) will be called the “bottom-coin.” Themerchant can verify the validity of the coins between the pseudonym-topand the bottom-coin by recursively hashing the bottom-coin C_(i) for itimes (see formula (11)). The computation will finally result in thepseudonym-top C₀. To this end, the signature of the bank on thepseudonym-top can be verified (see (12)). However, the merchant willonly accept these coins provided that Alice has also correctly signedthe pseudonym-top using the one-time signature scheme that was describedpreviously. Alice must generate the signature with the use of a PSG thatcan be hashed to f(x₁). In addition, Alice must also generate a secondSSG r₂ and send the hashed value of the second PSG f(x₂) to themerchant. The usage of the second PSG will be clear in a moment. A nicefeature in Schnorr's scheme is that all of the SSG, PSG pairs can bepre-computed by the signer before the signing time. Thus, there will beno problem for Alice to prepare these pairs for future use.

Upon acceptance of these i coins, the merchant M₁ should digitally signthe bottom-coin C_(i) together with the hashed value f(x₂), i.e. M₁should send message Sig_(M1)(C_(i), f(x₂), (n−i)) back to Alice. Thissignature will serve the same function as the bank's signature for thepseudonym-top in (12). Namely, Alice can use it to spend the rest of thecoins C_(i+1), C_(i+2), . . . C_(n) by using C_(i) as a new top. Forthis reason, the term “current-top” will be used to refer to C_(i). Bycombining the bottom-coin with a PSG, the bottom-coin is turned into acurrent-top. Now this quantity can no longer be spent as a coin. Later,the merchant M₁ can use C₀, C_(i) to redeem i coins from the bank B aswill be described in more detail below.

Describing now a general setting, suppose Alice has spent j (j<n) coinsto k−1 previous merchants M₁, M₂,. . . , M_(k−1)(some or all of them maybe the same merchant) and she now holds the data Sig_(Mk−1)(C_(j),f(x_(k)),(n−j)), i.e. the current-top and the hashed value of a PSGusable for the next payment. Here, M_(k−1) is the merchant with whomAlice has shopped most recently. Under this general setting, we willspecify the payment protocol with which Alice pays i coins to the nextmerchant M_(k) for k>0. These i coins are under the current-top C_(j).Note that in the above description of the initial payment, we havedescribed a special case where j=0, k=1 and M₀=B.

Payment A M _(k): Sig_(B)(C ₀ , g(v), f(x ₁), n), Sig_(Mk−1)(C _(j) ,f(x _(k)), (n−j)), Cert(M _(k−1) , P _(Mk−1)), C _(j+i) , i, timestamp,e _(k) , y _(k) , f(x _(k+1)), Cert(Alice_id, v)

Here e_(k)=h(C_(j), M_(k), timestamp, f(x_(k)) and y_(k)=(r_(k)+se_(k)mod q). Upon receipt of this payment message, the merchant M_(k) willfirst verify the spending signature on the current-top C_(j). This is bycomputing z_(k) from Equation (5) as follows:

z _(k)=(a ^(yk) v ^(ek) mod p)

and checking if

e _(k) =h(C _(j) , M _(k), timestamp, f(z _(k)))

If the equation holds, the merchant will further check whether thespending signature has been correctly created. This is to check whetherthe public key v that he has used in verifying the spending signaturecan be hashed to g(v) and the quantity z_(k) can be hashed to f(x_(k)).Here g(v) has been signed by the bank in the pseudonym-top, and f(x_(k)has been signed by the previous merchant M_(k−1) in the current-top. Thevalidation of such correctness will be in conjunction with thevalidation of the coins between the current-top and the bottom-coin. Themerchant will perform the validation by repeatedly hashing thebottom-coin C_(j+i) for i times to reach the current-top C_(j), andfurther hashing it for another j times to reach the pseudonym-top C₀followed by verifying the bank's digital signature. In this scheme, eachtime Alice spends coins under the current-top, she is required to signthe current-top. Thus, she cannot double spend even a single coin undereach current-top.

If everything goes well, these i coins will be accepted. If there arestill unspent coins left under the bottom-coin C_(j+i), then there is aneed to make change. In such a case, the merchant M_(k) should send thefollowing message back to Alice:

Change M _(k A:) Sig_(Mk)(C _(j+i) , f(x _(k+1)), (n−j−i)), Cert(M _(k), P _(Mk))

With the signed data in the message “Change”, the bottom-coin C_(j+i)becomes the new current-top and Alice can further spend the rest of thecoins under it.

By recursively hashing the quantity C_(n) in the construction of coins,we use hash function h( ) to serve the role of a counter. These hashedquantities are not worth any value if they are not properly signed withcorrect spending signatures. Therefore, some usually required hashfunction properties, such as non-invertibility, collision-resistance,etc, are not essentially required here for h( ). In particular, theissue of information entropy loss due to repeatedly hashing a piece ofdata for n (n can be a large number) times need not be a concern here.Being able to invert h( ) does not lead to an ability to spend therevealed values as coins if one cannot correctly generate a spendingsignature.

Note that although the scheme lets a merchant generate a new current-top(by combining a new usable PSG and the bottom-coin with a digitalsignature), this does not mean that a subsequent merchant has to trustany previous merchant in that he has integrated a good usable PSG withthe current-top. The usability of the PSG can be verified by the nextmerchant who is to validate some coins under the current-top. Alice hasfreedom to choose any PSG she likes. It is purely Alice's interest tolet each merchant combine a good PSG into the current-top. Using an oldPSG will risk disclosing her private key, whereas using a bad PSG (e.g.with an unknown SSG), Alice will be unable to sign the spendingsignatures correctly for the rest of the coins; namely, the coins underthe current-top will be wasted.

It will further be seen that no merchant is able to help Alice bycreating for her different copies of current-tops which are combinedwith different usable PSG's. The merchant M_(k) can redeem the value ofthe i coins from the bank B by depositing the following data:

Deposit M _(k) z,900 B: Sig_(B)(C ₀ , g(v), f(x ₁), n), Sig_(Mk−1)(C_(j) , f(x _(k)(n−j)), Cert(M _(k−1) , P _(Mk−1)), Sig_(Mk)(C _(j+i) ,f(x _(k+1)), (n−j−i)), Cert(M _(k) , P _(Mk)), timestamp, e _(k), y_(k), E(x _(k))

These data are analogous to the coin-deposit in (8) above. The signatureof the previous merchant on the current-top C_(j) is needed in order toallow the current merchant M_(k) to correctly redeem i coins. Themerchant M_(k) cannot redeem coins above the current-root (e.g. if hehas intercepted the message “Deposit” sent from the previous merchantM_(k−1)) without being detected. The bank will eventually find thatM_(k−1) and M_(k) claim the same coins where the spending signature forthe “current-top” above these coins does not support M_(k) (a wrongmerchant id in the spending signature).

Upon receipt of the message “Deposit”, the bank will check duplicationof the coins between the current-top C_(j) and the bottom-coin C_(j+i).If any coin C_(l) for j<l<(j+i) is found in the database, a fraud hasbeen detected. The bank can differentiate double spending from doubledepositing, and deal with these frauds accordingly (see below). Ifeverything is correct, it will credit the merchant and archive some ofthe data in the coin-deposit. Note that for hashed values as coins, onlythose that have been signed by the spender and merchants (i.e. eachcurrent-top) need to be archived against fraud.

The merchant's entitlement to make a signature that combines abottom-coin with a hashed PSG (hence turning that bottom-coin into a newcurrent-top) does not mean that he is able to help Alice to make many“current-tops” that are combined with different usable PSG's. Assumethat the merchant M_(k) helps Alice by making the following twodifferent “current-tops” to be viewed by subsequent merchants:Sig_(Mk)(C_(j+i),f(x), (n−j−i)); and Sig_(Mk)(C_(j+i), f(x′), (n−j−l));where x≢x′ and l may or may not be equal to i. Notice that for this helpto make sense, Alice must not be asked to make more than one spendingsignature on any current-top of these two coins; in other words,although these two signatures form two bottom-coins viewed by themerchant M_(k), he must not deposit both of them because their commoncurrent-top will identify him to be double depositing. The intention ofthis help is to let Alice use these different “current-tops” laterwithout disclosing her private key (because of different PSG's used,even if l=i). However, the two subsequent merchants (possibly includingM_(k) himself) who receive coins under these two “current-tops” willhand them in as the second signature chunk in their respective messages“Deposit.” This is equivalent to performing double deposit by themerchant M_(k) Namely, if the merchant helps Alice to double spend inthis way, the deposit data from other merchants will reveal hisidentity.

Having described an example of the invention, the advantages of theinvention, or at least of the example thereof, can be summarised asfollows:

(a) Spender's anonymity: as long as the spender does not double spend,the bank does not know who has spent the money. However, this is not astrong sense of untraceability because a collusive merchant can providethe bank with the spender's identity. It is believed that this weaksense of anonymity will be acceptable by many users as they will regardthe convenience of sending money over the Internet to outweigh theextremely small probability of collusions between a bank and a largenumber of merchants. People's attitude toward sending money over theInternet is likely to change. For instance, sending a few cents or acouple of dollars over the Internet will no longer be considered as“dangerous” as sending one's credit-card number.

(b) Identifying double spender with strong proof. The identification iseffective; the deterrence on double spending is strong; it is simple forthe bank to require revocation of the double spender's public-keycertificate.

(c) Using no on-line banks for making payment.

(d) Being independent of using tamper-resistant devices. Thus, thetechnique can readily be deployed over today's Internet.

(e) Coin sub-divisible to arbitrary denominations. For instance, a newchain of coins can worth 10 dollars with each coin worth 1 cent (i.e. nin the pseudonym-top is equal to 1,000). After Alice has sent thecurrent-top to the merchant, she can continuously release the coinsunder it, until (s)he feels enough services/goods have been purchased.No further signature is needed for these coins. This is particularlysuitable for web-based interactive information page purchase.

(f) Small data size for coins. Paying a merchant with arbitrary numberof coins (up to n), the message “Payment” can readily be organisedwithin one kilobyte (including key certificates). It is believed thatthis size of data may well be smaller than the previous techniques foroff-line cash coins independent of using smartcards. The storage ofarbitrary number of coins uses the same data size as that in the“Payment” message.

(g) No need of interactive communications between purchaser andmerchant. In fact, the message “Change” is needed only to give change.Thus, a payment can be made in a single email.

Having described an example of the invention, it will be appreciatedthat many modifications may be made to it, and that it may have manyother applications. For example, as explained above, if a spenderdouble-spends, the bank can discover the sender's private key s andpublic key v. It is therefore then possible for a fraudulent bankemployee to spend the remainder of the spender's money, rather thanhaving the sender's public-key certificate revoked. In order to dealwith this, the example scheme may be modified as follows:

a) A spender has a first certified public key v as before, a secondcertified public key v′, and two corresponding private keys s and s′,respectively.

b) Referring to FIG. 1, a second SSG r′ is chosen such that r′<q, and asecond PSG x′ is calculated such that:

x′=a ^(r′)mod p.

c) Referring to FIG. 5, a third signature part e′ is calculated suchthat:

e′=h(C, merchant_id, timestamp, x′)

i.e. based on x′ as in Schnorr's scheme, rather that f(x′) as in themain example described above.

(d) A fourth signature part y′ is calculated such that:

y′=((r′+s′e′)mod q

(e) The transmission which is required to be sent to Bob is in the form:

Coin, merchant_id, timestamp, e, y, e′, y′, Cert(Alice_id, v, v′)

i.e. also including the third and fourth signature parts e′, y′, andincluding the second public key v′ in the public key certificate. Itshould be noted that, although the first public key v is integrated inCoin, the second public key v′ is not.

(f) Referring to FIG. 6, Bob additionally calculates a second apparentPSG z′ such that:

z′=a ^(ry′) v ^(re′)modp

(g) Bob then carries out a fourth check as follows:

e′=h(C, merchant_id, timestamp, z′)?

and if that check fails, then Coin is rejected as invalid in Step 70.

In the case of a double spend, the bank employee may be able toascertain the spender's first private key s as discussed in the mainexample, but will not be able to ascertain the second private key s′ andtherefore not be able to misappropriate the remainder of the money.

What is claimed is:
 1. A method of identifying a private key of a userre-using a digital coin, comprising the steps of: taking a message to besigned by the user; signing the message into a digital signature of theuser, the digital signature being generated as a function of thatmessage using public and secret signature generators of the user, and aprivate key of the user; and transmitting the signed message over anetwork to a receiver; wherein: the message to be signed by the userincorporates a first value which is a first predetermined function ofthe user's public signature generator, and upon re-use of the messagesubtracting the secret signature generator from the digital signature toenable the private key to be determined.
 2. A method as claimed in claim1, wherein the first predetermined function is a secure one-way hashfunction.
 3. A method as claimed in claim 1, wherein the signatureincludes a second value which is a second predetermined functiondependent on the first value.
 4. A method as claimed in claim 3, whereinthe second predetermined function is a secure one-way hash function. 5.A method as claimed in claim 3, wherein the signature includes a thirdvalue which is a third predetermined function of the secret signaturegenerator, the second value, and the private key of the user.
 6. Amethod as claimed in claim 1, wherein the message to be signed by theuser incorporates another value which is another predetermined functionof a public key of the user.
 7. A method of verifying a signed messagereceived over a network, the signed message purporting to have beentransmitted in accordance with the method of claim 6, comprising thesteps of: calculating an apparent public signature of the user using thesigned message, and a public key of the user; calculating a furthervalue which is the predetermined function of the apparent publicsignature generator; and comparing the further value with the valueincorporated in the received signed message.
 8. A method as claimed inclaim 7, wherein the digital signature includes a second value which isa second predetermined function dependent on the first value, includingthe further steps of: calculating a sixth value which is the secondpredetermined function of the fifth value; and comparing the sixth valuewith the second value included in the received signature.
 9. A method asclaimed in claim 7, wherein the message to be signed by the senderincorporates a fourth value which is a fourth predetermined function ofa public key of the sender including the further steps of: calculating aseventh value which is the fourth predetermined function of a public keyof the sender received over the network; and comparing the seventh valuewith the fourth value incorporated in the signed message.
 10. A methodas claimed in claim 6, wherein the fourth predetermined function is asecure one-way hash function.
 11. A method of verifying the public keyof a user of a signed message received over a network, the signedmessage purporting to have been transmitted in accordance with themethod of claim 6, comprising the steps of: calculating a seventh valuewhich is the fourth predetermined function of the public key of the userreceived over the network; and comparing the seventh value with thefourth value incorporated in the signed message.
 12. A method accordingto claim 1, wherein the message represents a sum of money.
 13. A methodof identifying a private key of a user re-using a digital coin,comprising the steps of: taking a message to be signed by the user;signing the message into a digital signature of the user, the digitalsignature being generated as a function of that message using public andsecret signature generators of the user, and public and private keys ofthe user; and transmitting the signed message over a network to areceiver; wherein: the message to be signed by the user incorporatesanother value which is another predetermined function of the public keyof the user, and upon re-use of the message subtracting the secretsignature generator from the digital signature to enable the private keyto be determined.
 14. A method as claimed in claim 13, wherein thefourth predetermined function is a secure one-way hash function.
 15. Amethod of verifying the public key of a user of a signed messagereceived over a network, the signed message purporting to have beentransmitted in accordance with the method of claim 14, comprising thesteps of: calculating a further value which is the another predeterminedfunction of the public key of the user received over the network; andcomparing the further value with the another value incorporated in thesigned message.
 16. A method according to claim 13, wherein the messagerepresents a sum of money.
 17. Apparatus for identifying a private keyof a user re-using a digital coin, comprising: a store for taking amessage to be signed by the user; a signature generator for signing themessage into a digital signature of the user, the digital signaturebeing generated as a function of that message using public and secretsignature generators of the user and a private key of the user, andwherein the signature generator is arranged so that (1) a value which isa predetermined function of the user's public signature generator isincorporated into the message to be signed by the user and (2) uponre-use of the message the secret signature is subtractable from thedigital signature for enabling the private key to be determined; and atransmitter for transmitting the signed message over the network to areceiver.
 18. Apparatus for identifying a private key of a user re-usinga digital coin comprising: a store for taking a message to be signed bythe user; a signature generator for signing the message into a digitalsignature of the user, the digital signature being generated as afunction of that message using public and secret signature generators ofthe user, public and private keys of the user, and wherein the signaturegenerator is arranged so (1) a value which is a predetermined functionof the public key of the user and (2) upon re-use of the message thesecret signature is subtractable from the digital signature for enablingthe private key to be determined and is incorporated into the message tobe signed by the user; and a transmitter for transmitting the signedmessage over the network to a receiver.